[レポート] 開発者のためのクラウド・ネットワーキング ガイド #AWSreInvent #BOA207

こんにちは、SHIOです。

開発者のための クラウド・ネットワーキング ガイド というセッションに参加しました。

セッションタイトル:
BOA207 | A developer’s guide to cloud networking

概要

Today, website accessibility depends on robust cloud networking. This session offers insights for developers to help them clearly understand the fundamentals of AWS networking to prevent the dreaded “this site can’t be reached” error messages. Explore essential AWS components like VPCs, subnets, routing, and security groups to understand their significance in cloud networking. Leave equipped with methodologies and tools to build accessible, available cloud-based applications and websites. Architects, developers, and technology decision-makers alike can gain takeaways to ensure that websites remain reachable in the cloud.

　

今日、Webサイトのアクセシビリティは堅牢なクラウドネットワーキングに依存しています。このセッションでは、開発者がAWSネットワーキングの基本を明確に理解し、「このサイトにはアクセスできません」という恐ろしいエラーメッセージを防ぐための洞察を提供します。VPC、サブネット、ルーティング、セキュリティグループのようなAWSの必須コンポーネントを探求し、クラウドネットワーキングにおけるそれらの重要性を理解します。アクセシブルで可用性の高いクラウドベースのアプリケーションやWebサイトを構築するための方法論やツールを習得します。アーキテクト、開発者、技術的な意思決定者は、クラウド上でウェブサイトがアクセス可能であることを保証するためのヒントを得ることができます。

レポート

まず初めにスピーカーの方から以下のようなお話がありました。

・セッションに参加している人々はそれぞれ異なるバックグラウンドを持っていることを理解しています
・開発者の仕事はアプリケーションを開発することであるため、ネットワークの問題で時間を割くことは望んでいないでしょう
・今回のセッションでは、開発者、エンジニア、アーキテクトかどうかに関わらず物事をシンプルにし、AWSのクラウドネットワークについて話します

アジェンダ

以下、アジェンダです。

• AWS Global Infrastructure
• Amazon VPC and security basics
• Connectivity in AWS
• Hybrid connectivity
• Traffic monitoring and visibility

Poll

次に poll がありました。スクリーンに表示された QRコード を読み取ってアンケートに回答、その場で会場内でのアンケート結果が分かるというものです。poll があるセッションは初めてだったので面白かったです。

Poll: What percentage of your day on average is spent troubleshooting the network?
(ネットワークのトラブルシューティングに費やす時間は、1日の平均で何パーセントですか？)

選択肢は以下です。

• 0% - 10%
• 11% - 20%
• 21% - 30%
• 31% or more
• Unsure

投票結果はこのような形になりました。

0% - 10% が1番多いですね。私もここに投票した気がします。
ネットワークのトラブルシューティングに費やす時間が少ないということなので、これは良い結果ですね〜とスピーカーの方も言っていました。

AWS Global Infrastructure

ここからAWS基盤に関しての概要の説明がありました。

• 32 のリージョンがある
  これはどういう意味かというと、世界中にある32の地域がアプリケーションを配置する場所であり、通常は顧客のできるだけ近くに配置される
• リージョンの中には 102 のAZ
• 600 以上の Point of Presence (POP) ネットワーク (CloudFront, Route53, AWS Global Accelerator)

AWS Region design

• リージョンとは、アベイラビリティ・ゾーンを実際に集積する世界中の地理的なエリアのこと
• 高可用性、スケーラビリティ、高耐障害性を実現するために複数のAZで構成される
• 通常それぞれのリージョンに3つのAZがある

AWS Availability Zone (AZ) design

• アベイラビリティ・ゾーンとは、クラスタ化されたデータセンターのこと
• 高可用性、耐障害性、スケーラビリティ
• 60マイル（100km）以内で物理的に分離されたデータセンター
  ※ 万が一AZ近くで洪水や地震が起きたりした場合に備えている
  ※ そうすることで他のAZは高可用性を保つことができる
• 低レイテンシーによるリアルタイムのデータ複製

Bulding a VPC

• 該当リージョンで作成された VPC はそのリージョン全体にまたがる
• VPC は複数の AZ にまたがることはできるけど、1つのリージョンのみ
• VPC を作成したらサブネットを作成する。さらにサブネット内に EC2インスタンス を作成する
• 複数の AZ を使用する場合は高可用性となる
• これが VPCアーキテクチャ の基本

Amazon VPC and security basics

このセクションでは以下についての説明がありました。

• VPC内/外 での使用するIPアドレスについて
• IP range (CIDR)
• サブネットについて
• インターフェース
• ルーティング
• NACLs
• セキュリティグループ

Connectivity in AWS

Connecting to the internet

ひとつ前の『Amazon VPC and security basics』のセクションでは、VPC間やVPCからパブリックのAWSサービスへのアクセスについてのお話でしたが、こちらのセクションでは VPC からインターネットへのアクセスについての説明がありました。
図にあるように4つのサブネットにEC2インスタンスがそれぞれ起動していますが、こちらを例にしての説明でした。

★ 3つの必要なこと

• Internet Gateway を VPC にアタッチする
• 外部IPv4アドレスの割り当て
• VPCのルートテーブルの更新
  ※ IPv4アドレスだけでなく、IPv6アドレスを使用している場合はルートテーブルにIPv6アドレスのルールも追加すること

EC2インスタンスのIPアドレス確認方法

ローカルIPアドレス

[ec2-user@ip-172-31-16-14 ~]$ ifconfig
enX0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9001
        inet 172.31.16.14  netmask 255.255.240.0  broadcast 172.31.31.255

パブリックIPアドレス

[ec2-user@ip-172-31-16-14 ~]$ curl -w "\n" -H "X-aws-ec2-metadata-token: $TOKEN" \
> http://169.254.169.254/latest/meta-data/public-ipv4
34.219.144.122

Egress-only internet gateway

パブリック/プライベートサブネット、ルーティング、NAT Gatewayの基礎的な説明があったあと、Egress-only internet gateway についての説明もありました。

• IPv6トラフィックでのみ使用ができる
• インスタンス -> インターネットのアクセスはできるが、インターネット -> インスタンス のアクセスはできない

Connecting from the internet

インターネットからEC2インスタンスへのアクセスについてのセクションです。

★ 5つの必要なこと

1. パブリックIP
2. セキュリティグループの許可設定
3. NACLの許可設定
4. インターネットゲートウェイのアタッチ
5. インターネットゲートウェイへのルーティング設定

VPC gateway endpoints

• AWSのパブリックサービスにVPCからプライベートな接続が行えるもの
• インターネットゲートウェイ、NATゲートウェイ、VPNなど必要なし
• 接続できるパブリックサービスは S3 と DynamoDB
• 上記サービスに VPC から接続する場合、データ転送料金はかからない

VPC interface endpoints

• インターフェイスエンドポイント は PrivateLink を利用している
• つまり、VPC と AWSサービスの間にプライベートで安全な接続が提供される
• 利用できるサービスは何百もあるが、基本的には次のようなことを行える
  -- インターフェイスエンドポイントを作成すると、そのインターフェイスエンドポイントがAZ内に ENI を作成する
  -- もし CloudWatch と通信を行いたいときはそのインターフェイスエンドポイントと通信をすることになる
  -- 直接 PrivateLink を利用してアクセスする

スピーカーの方はゲートウェイエンドポイントとインターフェースエンドポイントの違いについてよく質問されるとのことで、つまり上記の内容のとおり2つの違いは、

• ゲートウェイエンドポイントは、ルートテーブル内のルーティングを使用している
• インターフェイスエンドポイントは、AWS PrivateLink を使用しIPアドレスまたはENIを取得する(DNSを使用してサービスと通信することもできる)

AWS PrivateLink

• VPC、サポートされるAWSサービス、オンプレ間のプライベート接続をインターネットに公開することなく提供できる
• NLBを使用
• インターネットゲートウェイ、NATゲートウェイ、VPNなど必要なし

Connecting between VPCs

• Amazon VPC peering
  -- VPC 当たりのアクティブな VPC ピアリング接続は 125
  -- 帯域幅の制限なし
  -- ルーティング接続は双方向

• AWS Transit Gateway
  -- Transit Gateway あたりのアタッチメント数 5000
  -- アタッチメントあたり最大 100Gpbs
  -- ルーティング接続は双方向

• AWS PrivateLink
  -- コンシューマーVPCの数に制限なし
  -- ENI あたり 1秒あたり 100GBPS まで拡張可能
  -- アプリケーションの接続性はクライアントからサーバへ
  -- 一方向

Hybrid connectivity

VPCからの接続、VPC間の接続の次に、ハイブリッド接続についての説明がありました。
データセンターからAWSに接続した場合、いくつかのオプションがあります。

• Site-to-Site VPN
• AWS Direct Connect (専用の直接接続が必要な場合はこれ)
  Direct Connect Gateway (高可用性を提供したい場合はこちらも検討)
• Transit Gateway (Transit Gateway + VPN, Transit Gateway + Direct Connectという構成が可能)

Traffic monitoring and visibility

Poll がありました。

Poll: What's your biggest challenge when it comes to troubleshooting network problems in the cloud?
(クラウドのネットワーク問題のトラブルシューティングで一番苦労することは何ですか？)

選択肢は以下です。

• Security groups/NACLs
• DNS
• Routing
• VPC configuration
• Other

全部選びたい気持ちがありますが、私は Routing に投票しました！

投票結果は以下のようになりました。

Routing が一番多く、 SG/NACLs も投票率が高いですね。これらをカバーするには、VPC内で使用できる2つのオプションがあります。

Amazon VPC flow logs

• Amazon VPC と AWS Transit Gateway をサポート
• VPC および Transit Gateway の IPトラフィックに関する非リアルタイムのメタデータ情報を取得
• ネットワークトラフィックパターンの可視性向上 (ネットワークセキュリティの監視と問題のとラブルシューティング)
• フローログは Amazon CloudWatch Logs, Amazon S3, Amazon Kinesis Data Firehose に送ることができる

Amazon VPC Traffic Mirroring

• EC2インスタンスのENIからネットワークトラフィックをミラーリングする機能
• ENI からネットワークトラフィックをコピーできる
• パケット内容の取得
• コンテンツ検査
• 脅威モニタリング
• トラブルシューティング
• ペイロードを含むネットワークトラフィックのコピー

Reachability Analyzer

• VPC内のソースリソースとディスティネーションリソース間の接続性テストを実行できる構成分析ツール
• ネットワークの設定ミスが原因で発生する接続性の問題をトラブルシューティングできる

まとめ

“this site can’t be reached” というエラーメッセージを防ぐための洞察を提供する、とセッションディスクリプションに書いてあったので、トラブルシューティングメインの内容かと思いましたがネットワーク関連のインフラやサービスについてのベーシックなお話が多かったです。自分の知識の復習をしつつ、サービス名や概要は知っていてもあまり馴染みのないサービス、あまり詳しくないサービスについても学ぶことができました。知っていることでも改めてじっくり聞くと勉強になりますね！ Traffic Mirroring と Reachability Analyzer は検証してみたいなと思いました。

レポートは以上です。
ここまで読んでいただきありがとうございました！

資料

Amazon Virtual Private Cloud
Traffic Mirroring
Reachability Analyzer